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DETAILED ACTION 

Claim Rejections - 35 USC § 101 

1. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of 
matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the 
conditions and requirements of this title. 

2. Claims 1-57 are rejected under 35 U.S.C. 101 because the claimed invention is 
directed to non-statutory subject matter. 

Regarding the device in claims (1-16 and 49-51) and the methods in claims (17-32 
and 52-54) fails to fall within a statutory category of invention they are directed to a 
software logic which is non- statutory subject matter. For a method claim to satisfy the 
35 U.S.C. 101 , it must (1 ) be tied to another statutory class or (2) transform the 
underlying subject matter. Claims (17-32 and 52-54) are not tied to another statutory 
class and do not transform the underlying subject matter. 

Claims (33-48 and 55-57) merely offers a computer program which is non- statutory 
subject matter 

Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 



Application/Control Number: 10/576,789 Page 3 

Art Unit: 4173 

4. Claims 1-57 are rejected under 35 U.S.C. 103(a) as being unpatentable over Fluss 
(USPN 6,304,578 B1) in view of Pandya (US 2004/0010612 A1) hereinafter referred to 
as Fluss and Pandya respectively. 

Regarding claim 1 , Fluss discloses a communication device for realizing 
communication with data (data packet see abstract and col: 1 line 1) distributed to a 
plurality of connections (shared data channels see abstract and col: 1 lines 66-67 and 
col: 2 line 1). 

Fluss does note that explicitly discloses a function of storing information for restoring 
data distributed to the plurality of connections within a header of said data. However 
Pandya teaches a function of storing information for restoring data (multiple memory 
descriptors to store/retrieve packet/data, see [001 19] toward the end and FIG 21) within 
a header (packet header see [01 35]) of said data 

Thus it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to use and modify the apparatus of Fluss and couple with packet 
header and memory descriptors taught by Pandya in order to store and retrieve data. 

Regarding claim 2, note that Pandya teaches the communication device wherein 
said header is a connection header (packet header see [0135] also see header fields for 
TCP see [0120]). 
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Regarding claim 3, note that Fluss discloses the communication device which has a 
function of examining maximum values of a packet size allowed (maximum packet size 
agreed on see colon: 1 lines 36-37). Pandya teaches by a connection related to 
communication and unifying (fragmented packets are combined to form a complete 
packets see [01 12]) the smallest size among said packet size (TCP layer provides 
functions to fragment de-fragment the packets as per the path of maximum transfer unit 
MTU see [0101] toward the end) 

Regarding claim 4, note that Fluss discloses The communication device which has a 
function of examining maximum values of a packet size allowed (maximum packet size 
agreed on see coin: 1 lines 36-37) by a connection related to communication and 
communicating with a packet size equal to or less than the smallest size (near allowable 
maximum, packets smaller than the threshold see coin: 8 lines 1-20 among said packet 
size maximum values. 

Regarding claim 5, note that Pandya teaches the communication device wherein as 
information for restoring (multiple memory descriptors to store/retrieve packet/data see 
[001 19] toward the end and FIG 21 ) said data, a data length is stored (data checksum 
see [0097]). 

Regarding claim 6, Fluss discloses a communication device for realizing 
communication with data (data packet see abstract and cool: 1 line 1) distributed to a 
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plurality of connections (shared data channels see abstract and col: 1 lines 66-67 and 
col: 2 line 1). 

Fluss does not explicitly disclose by using connections by a transport protocol 
equivalent to OSI four layers including TCP, SCTP, UDP and DCCP, comprising 
a function of storing information for restoring data distributed to the plurality of 
connections within a header equal to or less than equivalence of four layers including 
TCP, SCTP, UDP and DCCP. However Pandya teaches connections by a transport 
protocol equivalent to OSI four layers including TCP, SCTP, UDP and DCCP, 
( protocols for transporting data see [0004] ) comprising; 
a function of storing information for restoring (multiple memory descriptors to 
store/retrieve packet/data see [00119] toward the end and FIG 21) data distributed to 
the plurality of connections within a header (packet header see [0135] )equal to or less 
than equivalence of four layers including TCP, SCTP, UDP and DCCP( protocols for 
transporting data see [0004] and [0007] ). 

Thus it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to made use of the disclosure of Fluss and combine it with the 
packet header and data flow process taught by Pandya in order to transport data across 
a network. 

Regarding claim 7, note that Fluss modified by Pandya teaches the communication 
device wherein information for restoring data (Pandya: multiple memory descriptors to 
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store/retrieve packet/data see [001 19]) distributed to the plurality of connections (Fluss 
(shared data channels see abstract and coin: 1 lines 66-67 and col: 2 line 1). 
Is stored within the header (Pandya: packet header sees [0135] also see header fields 
for TCP see [0120]) of the transport protocol (protocols for transporting data see [0004] 
and [0007]). 

Regarding claim 8, note that Fluss modified by Pandya teaches the communication 
device wherein information for restoring data (Pandya: multiple memory descriptors to 
store/retrieve packet/data see [001 19]) distributed to the plurality of connections (Fluss 
(shared data channels see abstract and col: 1 lines 66-67 and col: 2 line 1). 
Is stored in an option field within the header (Pandya: packet header sees [0135] also 
see header fields for TCP see [01 20]) of the transport protocol (protocols for 
transporting data see [0004] and [0007]). 

Regarding claim 9, note that Fluss modified by Pandya teaches The communication 
device wherein information for restoring data (Pandya : multiple memory descriptors to 
store/retrieve packet/data see [001 19] ) distributed to the plurality of connections(Fluss: 
shared data channels see abstract and col:1 lines 66-67 and col:2 line 1) is stored in a 
part of a timestamp (Fluss : time elapsed see col:6 lines 56-57) field of an option field 
within the header of the transport protocol (Pandya: multiple memory descriptors to 
store/retrieve packet/data see [001 19] toward the end and FIG 21) and see packet 
header [0135]). 
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Regarding claim 10, note that Fluss modified by Pandya teaches The 
communication device wherein information for restoring data (Pandya: multiple memory 
descriptors to store/retrieve packet/data see [001 19]) distributed to the plurality of 
connections (Fluss: shared data channels see abstract and col: 1 lines 66-67 and col: 2 
line 1 ) is stored within an IP header (Fluss: IP header contains information's see colnl 
lines 15-16). 

Regarding claim 1 1 , note that Fluss modified by Pandya teaches The 
communication device wherein information for restoring data (Pandya: multiple memory 
descriptors to store/retrieve packet/data see [0011 9]) distributed to the plurality of 
connections (Fluss (shared data channels see abstract and col: 1 lines 66-67 and col: 2 
line 1) is stored in a fragment field within an IP header (Pandya: fragmented IP packets 
see [0112]. 

Regarding claim 12, note that Fluss modified by Pandya teaches The 
communication device , which has a function of examining an MTU (Pandya IP packet 
fragmentation base on the on the maximum transfer unit 'MTU' see [0007] usable by the 
plurality of connections ((Fluss (shared data channels see abstract and col:1 lines 66-67 
and col:2 line 1) by a path MTU ( Pandya : segments data unit to segments 'path 
MTU'see [0121]) discovery option and unifying MTU of the respective connections to 
the smallest MTU obtained by said examination . (Pandya: Fragmented packets are 
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combined to form a complete packets see [01 12]. 

Regarding claim 13, note that Pandya teaches a communication device wherein, 
wherein a transmission side stores a distributed data length in said information for 
restoring (multiple memory descriptors to store/retrieve packet/data see [001 19] toward 
the end and FIG 21) said distributed data and a reception side refers to said data length 
to restore the data ( data checksum see [0097]) and (multiple memory descriptors to 
store/retrieve packet/data see [001 19]. 

Regarding claim 14, notes that Fluss discloses the communication device wherein a 
data size to be transferred (throughput the rate at which the data arrived see col: 2 lines 
29-35) to each connection at one time is changed according to a communication rate 
(effective throughput see col :2 lines 35-35). 

Regarding claim 15, note that Pandya teaches the communication device wherein 
data is restored by referring to the information for restoring data (multiple memory 
descriptors to store/retrieve packet/data see [001 19] toward the end and FIG 21). 

Regarding claim 16 , notes that Fluss discloses the communication device 
which has a function of, when a TCP communication rate is low (latency see col:7 line 
50) , reducing the volume of data to be transferred (improve throughput see 49) to each 
connection at one time and when the TCP communication rate becomes high, 
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increasing the volume of data to be transferred to each connection at one time(large 
packets and priority levels see col:7 lines 40 -65) 

Regarding claim 17, Fluss discloses a communication method for realizing 
communication with data(data packet see abstract and col: 1 line 1) distributed to a 
plurality of connections(shared data channels see abstract and col: 1 lines 66-67 and 
col:2 line 1). 

Fluss does not explicitly discloses the processing of storing information for restoring 
data distributed to the plurality of connections within a header of data. However Pandya 
teaches processing of storing information for restoring data( multiple memory 
descriptors to store/retrieve packet/data see [001 19]) distributed to the plurality of 
connections within a header (packet header see [0135] ) of data. Thus it would have 
been obvious to one of ordinary skill in the art at the time the invention was made to use 
and modify the apparatus of Fluss and couple with a packet header and memory 
descriptors taught by Pandya in order to store, retrieve and transport data. 

Regarding claim 18, note that Pandya teaches the communication method, wherein 
said header is a connection header (packet header see [0135] also see header fields for 
TCP see [0120]). 

Regarding claim 19, note that Fluss discloses the communication device of 
examining maximum values of a packet size allowed (maximum packet size agreed on 
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see coin: 1 lines 36-37). Pandya teaches by a connection related to communication and 
unifying (fragmented packets are combined to form a complete packets see [01 12]) the 
smallest size among said packet size (TCP layer provides functions to fragment de- 
fragment the packets as per the path of maximum transfer unit MTU see [0101] toward 
the end) . 

Regarding claim 20, note that Fluss discloses The communication device 
comprising processing of examining maximum values of a packet size allowed 
(maximum packet size agreed on see coin: 1 lines 36-37) by a connection related to 
communication and communicating with a packet size equal to or less than the smallest 
size (near allowable maximum, packets smaller than the threshold see coin: 8 lines 1- 
20) among said packet size maximum values. 

Regarding claim 21 , note that Pandya teaches the communication device wherein 
as information for restoring (multiple memory descriptors to store/retrieve packet/data 
see [001 19] toward the end and FIG 21 ) data, a data length is stored (data checksum 
see [0097]). 

Regarding claim 22, Fluss discloses a communication device for realizing 
communication with data (data packet see abstract and col: 1 line 1) distributed to a 
plurality of connections (shared data channels see abstract and col: 1 lines 66-67 and 
col: 2 line 1). 
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Fluss does not explicitly disclose by using connections by a transport protocol 
equivalent to OSI four layers including TCP, SCTP, UDP and DCCP, comprising 
the step of processing of storing information for restoring data distributed to the plurality 
of connections within a header equal to or less than equivalence of four layers including 
TCP, SCTP, UDP and DCCP. However Pandya teaches connections by a transport 
protocol equivalent to OSI four layers including TCP, SCTP, UDP and DCCP, 
( protocols for transporting data see [0004] ) comprising; 
a function of storing information for restoring (multiple memory descriptors to 
store/retrieve packet/data see [001 19] toward the end and FIG 21) data distributed to 
the plurality of connections within a header (packet header see [0135] )equal to or less 
than equivalence of four layers including TCP, SCTP, UDP and DCCP( protocols for 
transporting data see [0004] and [0007] ). 

Thus it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to made use of the disclosure of Fluss and combine it with the 
packet header and data flow process taught by Pandya in order to transport data across 
a network. 

Regarding claim 23, note that Fluss modified by Pandya teaches the communication 
method wherein information for restoring data (Pandya: multiple memory descriptors to 
store/retrieve packet/data see [001 19]) distributed to the plurality of connections (Fluss 
(shared data channels see abstract and col: 1 lines 66-67 and col: 2 line 1). 
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Is stored within the header (Pandya: packet header sees [0135] also see header fields 
for TCP see [0120]) of the transport protocol (protocols for transporting data see [0004] 
and [0007]). 

Regarding claim 24, note that Fluss modified by Pandya teaches the communication 
method wherein information for restoring data (Pandya : multiple memory descriptors to 
store/retrieve packet/data see [001 19]) distributed to the plurality of connections (Fluss 
(shared data channels see abstract and col: 1 lines 66-67 and col: 2 line 1). 
Is stored in an option field within the header (Pandya: packet header sees [0135] also 
see header fields for TCP see [01 20]) of the transport protocol (protocols for 
transporting data see [0004] and [0007]). 

Regarding claim 25, note that Fluss modified by Pandya teaches The 
communication method wherein information for restoring data (Pandya : multiple 
memory descriptors to store/retrieve packet/data see [001 19] ) distributed to the plurality 
of connections(Fluss (shared data channels see abstract and col:1 lines 66-67 and col:2 
line 1 ) is stored in a part of a timestamp (Fluss : time elapsed see col:6 lines 56-57) field 
of an option field within the header (Pandya : packet header see [0135] also see header 
fields for TCP see [0120]) of the transport protocol (Pandya: protocols for transporting 
data see [0004] and [0007] ). 
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Regarding claim 26, note that Fluss modified by Pandya teaches The 
communication method wherein information for restoring data (Pandya : multiple 
memory descriptors to store/retrieve packet/data see [001 19]) distributed to the plurality 
of connections (Fluss (shared data channels see abstract and col: 1 lines 66-67 and col: 
2 line 1) is stored within an IP header (Fluss: IP header contains information's see colnl 
lines 15-16). 

Regarding claim 27, note that Fluss modified by Pandya teaches The 
communication method wherein information for restoring data (Pandya : multiple 
memory descriptors to store/retrieve packet/data see [001 19]) distributed to the plurality 
of connections (Fluss (shared data channels see abstract and col: 1 lines 66-67 and col: 
2 line 1) is stored in a fragment field within an IP header (Pandya: fragmented IP 
packets see [0112]). 

Regarding claim 28, note that Fluss modified by Pandya teaches The 
communication method comprising processing of examining an MTU (Pandya: IP 
packet fragmentation base on the on the maximum transfer unit 'MTU' see [0007] 
usable by the plurality of connections (Fluss : shared data channels see abstract and 
col:1 lines 66-67 and col:2 line 1 ) by a path MTU ( Pandya : segments data unit to 
segments 'path MTU' see [0121]) discovery option and unifying MTU of the respective 
connections to the smallest MTU obtained by said examination (Pandya : Fragmented 
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packets are combined to form a complete packets see [01 12]. 

Regarding claim 29, note that Pandya teaches a communication method wherein, 
wherein a transmission side stores a distributed data length in said information for 
restoring (multiple memory descriptors to store/retrieve packet/data see [001 19] toward 
the end and FIG 21) said distributed data and a reception side refers to said data length 
to restore the data (data checksum see [0097]) and (multiple memory descriptors to 
store/retrieve packet/data see [001 19]). 

Regarding claim 30, notes that Fluss discloses the communication method 
comprising processing of changing a data size to be transferred (throughput the rate at 
which the data arrived see col: 2 lines 29-35) to each connection at one time is changed 
according to a communication rate (effective throughput see col: 2 lines 35-35). 

Regarding claim 31 , note that Pandya teaches the communication method 
comprising processing of restoring data by referring to the information for restoring data 
(multiple memory descriptors to store/retrieve packet/data see [001 19] toward the end 
and FIG 21). 

Regarding claim 32, notes that Fluss discloses the communication method 
comprising processing of, when a TCP communication rate is low (latency see col: 7 
line 50), reducing the volume of data to be transferred (improve throughput see 49) to 
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each connection at one time and when the TCP communication rate becomes high, 
increasing the volume of data to be transferred to each connection at one time (large 
packets and priority levels see col: 7 lines 40 -65) 

Regarding claim 33, Fluss discloses a program on a computer (computer 
implemented process see col:8 lines 43-50 )which operate for executing 
communication with data(data packet see abstract and col: 1 line 1) distributed to a 
plurality of connections(shared data channels see abstract and col: 1 lines 66-67 and 
col:2 line 1). 

Fluss does not explicitly discloses the processing of storing information for restoring 
data distributed to the plurality of connections within a header of data. However Pandya 
teaches processing of storing information for restoring data( multiple memory 
descriptors to store/retrieve packet/data see [001 19]) distributed to the plurality of 
connections within a header (packet header see [0135] ) of data. Thus it would have 
been obvious to one of ordinary skill in the art at the time the invention was made to use 
and modify the apparatus of Fluss and couple with a packet header and memory 
descriptors taught by Pandya in order to store/ retrieve data via computer program. . 

Regarding claim 34, note that Pandya teaches the program (programmable TCP/IP 
see [0037], wherein said header is a connection header (packet header see [0135] also 
see header fields for TCP see [01 20]). 
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Regarding claim 35, note that Fluss discloses the program (computer -implemented 
process see col: 8 lines 43- 64) which causes execution function of examining 
maximum values of a packet size allowed (maximum packet size agreed on see coin: 1 
lines 36-37). Pandya teaches by a connection related to communication and unifying 
(fragmented packets are combined to form a complete packets see [01 12]) the smallest 
size among said packet size (TCP layer provides functions to fragment de-fragment the 
packets as per the path of maximum transfer unit MTU see [0101] toward the end). 

Regarding claim 36, note that Fluss discloses the program (computer -implemented 
process see col:8 lines 43- 64) which causes execution of function of examining 
maximum values of a packet size allowed (maximum packet size agreed on see coln:1 
lines 36-37 ) by a connection related to communication and communicating with a 
packet size equal to or less than the smallest size (near allowable maximum , packets 
smaller than the threshold see coln:8 lines 1-20) among said packet size maximum 
values . 

Regarding claim 37, note that Pandya teaches the program which causes 
execution of function of storing a data length (data checksum see [0097] as information 
for restoring (multiple memory descriptors to store/retrieve packet/data see [001 19] 
toward the end and FIG 21) data. 
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Regarding claim 38, Fluss discloses a program which operate in a computer for 
executing (computer -implemented process see col:8 lines 43- 64) communication with 
data (data packet see abstract and col: 1 line 1 ) distributed to a plurality of connections 
(shared data channels see abstract and col: 1 lines 66-67 and col:2 line 1). 
Fluss does not explicitly disclose by using connections by a transport protocol 
equivalent to OSI four layers including TCP, SCTP, UDP and DCCP, comprising 
the function executing processing for storing information for restoring data distributed to 
the plurality of connections within a header equal to or less than equivalence of four 
layers including TCP, SCTP, UDP and DCCP. However Pandya teaches connections 
by a transport protocol equivalent to OSI four layers including TCP, SCTP, UDP and 
DCCP, ( protocols for transporting data see [0004] ) comprising; 
the function executing processing for storing information for restoring (multiple memory 
descriptors to store/retrieve packet/data see [001 19] toward the end and FIG 21) data 
distributed to the plurality of connections within a header (packet header see [0135] 
)equal to or less than equivalence of four layers including TCP, SCTP, UDP and DCCP( 
protocols for transporting data see [0004] and [0007] ). 

Thus it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to made use of the disclosure of Fluss and combine it with the 
packet header and data flow process taught by Pandya in order to provide 
programmable means of transporting data across a network. 



Regarding claim 39, note that Fluss modified by Pandya teaches the program 
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(Pandya : programmable TCP/IP see [0037]) which causes execution of function of 
storing information for restoring data (Pandya : multiple memory descriptors to 
store/retrieve packet/data see [001 19] ) distributed to the plurality of connections(Fluss 
(shared data channels see abstract and col:1 lines 66-67 and col:2 line 1). 
Is stored within the header (Pandya: packet header sees [0135] also see header fields 
for TCP see [0120]) of the transport protocol (protocols for transporting data see [0004] 
and [0007]). 

Regarding claim 40, note that Fluss modified by Pandya teaches the program 
(Pandya : programmable TCP/IP see [0037])which causes of function of storing the 
information for restoring data (multiple memory descriptors to store/retrieve packet/data 
see [001 19] ) distributed to the plurality of connections(Fluss (shared data channels see 
abstract and col:1 lines 66-67 and col:2 line 1).is stored in an option field within the 
header(Pandya : packet header see [0135] also see header fields for TCP see [0120]) 
of the transport protocol (Pandya: protocols for transporting data see [0004] and [0007] 
)■ 

Regarding claim 41 , note that Fluss modified by Pandya teaches The program 
which causes execution of function of storing information for restoring data (Pandya : 
multiple memory descriptors to store/retrieve packet/data see [001 19] ) distributed to the 
plurality of connections(Fluss (shared data channels see abstract and col:1 lines 66-67 
and col:2 line 1) is stored in a part of a timestamp (Fluss : time elapsed see col:6 lines 
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56-57) field of an option field within the header (Pandya : packet header see [0135] also 
see header fields for TCP see [01 20]) of the transport protocol (Pandya: protocols for 
transporting data see [0004] and [0007] ). 

Regarding claim 42, note that Fluss modified by Pandya teaches the program 
(Pandya : programmable TCP/IP see [0037]) which causes execution of the function of 
storing the information for restoring data (multiple memory descriptors to store/retrieve 
packet/data see [001 19]) distributed to the plurality of connections (Fluss (shared data 
channels see abstract and col:1 lines 66-67 and col:2 line 1) is stored within an IP 
header( Fluss : IP header contains information's see colnl lines 15-16). 

Regarding claim 43, note that Fluss modified by Pandya teaches The 
program which causes execution of the function of storing the information for restoring 
data (Pandya : multiple memory descriptors to store/retrieve packet/data see [001 19]) 
distributed to the plurality of connections (Fluss (shared data channels see abstract and 
col: 1 lines 66-67 and col: 2 line 1) is stored in a fragment field within an IP header 
(Pandya: fragmented IP packets see [01 12]). 

Regarding claim 44, note that Fluss modified by Pandya teaches The program 
which causes execution of the function of examining an MTU (Pandya: IP packet 
fragmentation base on the on the maximum transfer unit 'MTU' see [0007] usable by the 
plurality of connections (Fluss : shared data channels see abstract and col:1 lines 66-67 
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and col:2 line 1) by a path MTU ( Pandya : segments data unit to segments 'path MTU' 
see [0121]) discovery option and unifying MTU of the respective connections to the 
smallest MTU obtained by said examination (Pandya : Fragmented packets are 
combined to form a complete packets see [01 12]. 

Regarding claim 45, note that Pandya teaches a program which causes a 
transmission side to execute the function of storing a distributed data length ( data 
checksum see [0097]) in the information for restoring (multiple memory descriptors to 
store/retrieve packet/data see [001 19] toward the end and FIG 21) distributed data and 
a reception side to execute the function of referring to said distributed data length( data 
checksum see [0097]) to restore the data (multiple memory descriptors to store/retrieve 
packet/data see [00119]). 

Regarding claim 46, notes that Fluss discloses the program (computer - 
implemented process see col: 8 lines 43- 64) which causes execution of the function of 
changing a data size to be transferred (throughput 'the rate at which the data arrived' 
see col: 2 lines 29-35) to each connection at one time according to a communication 
rate (effective throughput see col: 2 lines 35-35). 

Regarding claim 47, note that Pandya teaches the program (programmable TCP/IP 
see [0037]) which causes execution of the function of restoring data by referring to the 
information for restoring data (multiple memory descriptors to store/retrieve packet/data 
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see [001 19] toward the end and FIG 21). 
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Regarding claim 48, notes that Fluss discloses the program which causes 
execution of the function (computer -implemented process see col:8 lines 43- 64) when 
a TCP communication rate is low (latency see col:7 line 50) , reducing the volume of 
data to be transferred (improve throughput see 49) to each connection at one time and 
when the TCP communication rate becomes high, increasing the volume of data to be 
transferred to each connection at one time (large packets and priority levels see col:7 
lines 40 -65) 

Regarding claim 49, notes that Fluss discloses a communication device .wherein 
a data size to be transferred to each at one time is changed (throughput 'the rate at 
which the data arrived' see col: 2 lines 29-35 ) according to a communication rate 
(effective throughput see col :2 lines 35-35). 

Regarding claim 50, note that Pandya teaches the communication device 
wherein data is restored by referring to the information for restoring data (multiple 
memory descriptors to store/retrieve packet/data see [001 19] toward the end and FIG 
21). 

Regarding claim 51 , note that Fluss discloses The communication device which has 
a function of, when a TCP communication rate is low (latency see col: 7 line 50), 



Application/Control Number: 10/576,789 Page 22 

Art Unit: 4173 

reducing the volume of data to be transferred (improve throughput see 49) to each 
connection at one time and when the TCP communication rate becomes high, 
increasing the volume of data to be transferred to each connection at one time (large 
packets and priority levels see col: 7 lines 40 -65) 

Regarding claim 52, notes that Fluss discloses the communication method according 
to comprising processing of changing a data size to be transferred (throughput 'the rate 
at which the data arrived' see col: 2 lines 29-35 ) to each connection at one time 
according to a communication rate (effective throughput see col :2 lines 35-35). 

Regarding claim 53, note that Pandya teaches the communication method 
comprising processing of restoring data by referring to the information for restoring data 
(multiple memory descriptors to store/retrieve packet/data see [001 19] toward the end 
and FIG 21). 

Regarding claim 54, note that Fluss discloses the communication method 
comprising processing of, when a TCP communication rate is low (latency see col: 7 
line 50), reducing the volume of data to be transferred (improve throughput see 49) to 
each connection at one time and when the TCP communication rate becomes high, 
increasing the volume of data to be transferred to each connection at one time (large 
packets and priority levels see col: 7 lines 40 -65) 
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Regarding claim 55, notes that Fluss discloses The program (computer - 
implemented process see col: 8 lines 43- 64) which causes execution of the function of 
changing a data size to be transferred (throughput 'the rate at which the data arrived' 
see col: 2 lines 29-35) to each connection at one time according to a communication 
rate (effective throughput see col: 2 lines 35-35). 

Regarding claim 56, note that Pandya teaches the program which causes execution 
(programmable TCP/IP see [0037]) of the function of restoring data by referring to the 
information for restoring data (multiple memory descriptors to store/retrieve packet/data 
see [001 1 9] toward the end and FIG 21 ). 

Regarding claim 57, note that Fluss discloses the program which causes execution 
of the function of, when a TCP communication rate is low (latency see col: 7 line 50), 
Reducing the volume of data to be transferred (improve throughput see 49) to each 
Connection at one time and when the TCP communication rate becomes high, 
Increasing the volume of data to be transferred (large packets and priority levels see 
Col: 7 lines 40 -65) to each connection at one time. 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to KHALID ABDALLA whose telephone number is 
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(571 )270-7526. The examiner can normally be reached on MONDAY THROUGH 
EVERY OTHER FRIDAY 7 AM TO 5 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, JINHEE LEE can be reached on 571-272-1977. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

IK. A./ 

Examiner, Art Unit 4173 



/Jinhee J Lee/ 

Supervisory Patent Examiner, Art Unit 4173 
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